Autoyaについてのドキュメント更新の前のウォーミングアップ

概要

Autoyaのドキュメントは2018に入ってから更新が止まっていてやばい。

最新で異様な機能が入っていたりするのでせめてその部分の更新をしないといけない。

あとなんかOSSドキュメントについていい感じのツールがあった気がするので漁ってみたい。

まずはメモを残す。

AssetBundle、Information、Manifest、OverridePoints

AssetBundles

基本戦略

Autoyaで実装されているAssetBundleの使用法は、オンデマンドなタイミングでのロード(必要であればABのダウンロードを含む)と、Preloadの2つに分かれる。

依存性解決あり。

Preloadは「使う前にAssetBundleをDLしておく」機能になっていて、PreloadListというjson形式のデータで「このシーンに入ったら最低限DLしておいてほしいABはこれ」とか

指定してDLさせることができる。

ちなみにPreloadListは何個、どんな分割で作ってもいい。

また、高度な使い方として、PreloadListの代わりに「サーバからPreloadListをダウンロードできるurl」を書くことができ、

ゲーム運営が進んだタイミングでサーバが返すデータを更新することで、「この画面まできたらあるABを全ユーザーが保持している見通しがあるのでダウンロードさせておく」などができる。

これによってサーバ側でユーザーが保持しているABのダウンロードタイミングを完全に制御することができる。

AssetBundleListとAssetGraphとの連携

AssetBundleListは、Autoyaで扱うABのリスト。json形式で、サーバから返したり初期バージョンをアプリケーションに入れておいたりできる。

ABListは運用に起因するリソース更新に応じて更新される。更新系はAutoyaのネットワークハンドリング起因でイベントとして発生し、かなりかっこいい実装になっている(雑)。

どこかのバージョンから、AssetGraph v1.3を同梱したUnityPackageを配布するようになった。

これにより、AssetGraph から AssetBundleList + AssetBundles の生成が可能になっている。

AssetGraph側のこの辺変えたいな～みたいな要素もちょこちょこあるのでそれはまた別に記載する。

AssetBundleListのマルチ化

要望としてちょいちょい上がっていた、AssetBundleListのマルチ化 = 複数リストでの運用に対応した。

これによって、AssetBundleを複数のリストに分け、管理/更新することが可能になった。

例えばアドベンチャーパートのABはめっちゃ更新頻度が高いんだけど他は別に、、みたいな時、Adv用のABListとそれ以外用のABListを別に更新したりできる。

トピックとしては簡単なんだけど実用には根本的にいろんな方面の難易度がある。

・使用できるAssetBundleListの情報はRuntimeManifestに記述する必要がある(リストの名前、ver、ダウンロードurlベースパスなど)

・サーバがクライアントのリソースを更新したくなったら、レスポンスヘッダーに特定の値を入れることでリストの更新を促すことができる。つまるところサーバドリブン。

・CDNにいろんなパスを掘ってAssetBundleを安置しておく必要がある

など。

マルチになったABList自体の作成はAssetGraphに依存していて、

AssetGraph Aを作る -> 

AssetGraphのハンドラにAutoya用のスクリプトアタッチする -> 

ビルド -> 

Aという名前のABList + ABが、プラットフォームやバージョンを加味された状態で生成される 

という流れになっている。

というかこれをAssetGraph使わずに人間が作るのは、APIを叩くだけにしたってほんとうにしんどい。仕様的に一つしか正解APIがないし、そのAPIは本当にメジャーじゃないし。

そのAPIって？

これ。

http://sassembla.github.io/Public/2016:08:22%2015-13-26/2016:08:22%2015-13-26.html

このAPIを人間が手で書いて使うのは無理。AssetGraphはその内部でこれを使っている。

AssetDatabaseの状況に左右されず、EditorのassetBundleドロップダウンを一切無視した状態で、manifestファイルを無制限に複数生成できる。

Information

お知らせ画面

Autoyaの中の特異点、ヤッチマッタ感の高いフルスクラッチUnityネイティブなWebViewでのお知らせ画面表示機能がある。

uGUIでHTMLタグを作って、HTMLを書くとそのレイアウトやConstraint、uGUIについてるスクリプトをバッチリ使用できる。

圧倒的にWebViewより高速で、メモリも食わず、コントロール感覚はUnityそのもので、全プラットフォームで動かせる。

HTMLタグ自体も外部からAssetBundleやらで輸入できるため、ぶっちゃけWebComponentsみたいなものをUnity上で実装したという表現があってる。

やりすぎた。

まだ完全じゃないので、無理して使わないでいいと思う(及び腰)

TextMesh Pro対応がもうすぐリリースされるので、そうすると態度でかくなると思う。すごく綺麗かつ高速。

Manifest

宣誓書

Autoyaでは、ビルド時に確定してブレない情報と、実行時に動的に更新されるような情報をManifestという形式で保存している。

BuildManifestとRuntimeManifestがそれ。

BuildManifestにはみんな大好きビルド番号や日時、constなデータなどをビルド時に書き込むことができ、これは不変になる。

RuntimeManifestには現在保持しているABListの情報などを入れることができ、永続化対象にもなっている。

Autoya.Manifest_なにやらで出てくる。

これらManifestのファイル内容は本来開発者が自由に書いていいと思っているんだけれど、

ABListのマルチ化に伴って「これは一体なんなんだ？」的なデフォルト設定がうまれてしまっているのがとてもまずいと思っている。

OverridePoints

上書き可能なポイント集

Autoyaではそのデフォルトの挙動でJWTでの認証や改ざん防止を放り込んであって、

それらのパラメータや動作はすべてOverridePoints.csというファイルを更新することで変更できる。

Frameworkとしての指針は、

「フローは決まってるんでどんなプロトコル使うかとかどう暗号化してファイル保存しようかは各自頑張って」

である。

んでその、OverridePointsがちょっと増減してるはずなので、それを書かねば。